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FOREWORD 


The  Trusted  Product  Evaluation  Questionnaire  is  the  latest  in  a  series  of  technical 
documents  that  are  being  published  by  the  National  Computer  Security  Center 
under  the  Technical  Guidelines  Programs.  It  is  the  goal  of  the  Technical  Guidelines 
Program  to  assure  that  each  process  in  the  Trusted  Product  Evaluation  Program  and 
the  features  of  the  Department  of  Defense  Trusted  Computer  Systems  Evaluation 
Criteria  will  be  discussed  in  detail  and  provide  the  proper  interpretations  with 
specific  guidance.  These  publications  are  designed  to  provide  insight  to  the 
Department  of  Defense  Trusted  Computer  Systems  Evaluation  Criteria  requirements 
for  the  computer  security  vendor  and  developer,  as  well  as  the  technical  evaluator. 

The  specific  questions  in  the  Trusted  Product  Evaluation  Questionnaire  provide  a  set 
of  good  practices  related  to  necessary  system  security  and  system  security 
documentation.  This  questionnaire  has  been  written  to  help  the  vendor  understand 
what  technical  information  is  required  concerning  the  system  for  a  product 
evaluation.  From  the  vendor's  responses,  the  evaluator  may  obtain  an 
understanding  of  the  security  of  the  system  applying  for  evaluation. 

As  the  Director,  National  Computer  Security  Center,  I  invite  your  recommendations 
for  revision  to  this  technical  guideline.  We  plan  to  review  this  document  when  the 
need  arises. 


Director  ^ 

National  Computer  Security  Center 


16  October  1989 


257-937  0-90-1  (QL  3) 
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INTRODUCTION 

The  principal  goal  of  the  National  Computer  Security  Center  (NCSC)  is  to  encourage 
the  widespread  availability  of  trusted  computer  systems.  In  support  of  this  goal  a 
metric  was  created,  the  Department  of  Defense  Trusted  Computer  System  Evalua¬ 
tion  Criteria  (TCSEC),  against  which  computer  systems  could  be  evaluated.  The 
TCSEC  was  originally  published  on  1 5  August  1983  as  CSC-STD-001-83.  In  December 
1985  the  DoD  adopted  it,  with  a  few  changes,  as  a  DoD  Standard,  DoD  5200.28-STD. 
DoD  Directive  5200.28,  "Security  Requirements  for  Automatic  Information  Systems 
(AISs),"  has  been  written  to  require,  among  other  things,  the  Department  of  De¬ 
fense  Trusted  Computer  System  Evaluation  Criteria  to  be  used  throughout  the  DoD. 
The  TCSEC  is  the  standard  used  for  evaluating  the  effectiveness  of  security  controls 
built  into  ADP  systems.  The  TCSEC  is  divided  into  four  divisions:  D,  C,  B,  and  A,  or¬ 
dered  in  a  hierarchical  manner  with  the  highest  division  (A)  being  reserved  for  sys¬ 
tems  providing  the  best  available  level  of  assurance.  Within  divisions  C,  B,  and  A 
there  are  subdivisions  known  as  classes,  which  are  also  ordered  in  a  hierarchical  man¬ 
ner  to  represent  different  levels  of  security  in  these  classes. 

The  NCSC  has  established  an  aggressive  program  to  study  and  implement  computer 
security  technology  and  to  encourage  the  widespread  availability  of  trusted 
computer  products  for  use  by  any  organization  desiring  better  protection  of  their 
important  data.  The  Trusted  Product  Evaluation  Program  and  the  open  and 
cooperative  business  relationship  being  forged  with  the  computer  and 
telecommunications  industries  will  result  in  the  fulfillment  of  our  country's 
computer  security  requirement.  We  are  resolved  to  meet  the  challenge  of 
identifying  trusted  computer  products  suitable  for  use  in  processing  all  types  and 
classifications  of  information. 


1.  PURPOSE 

The  NCSC  is  responsible  for  evaluating  commercial  products  through  an  indepen¬ 
dent  evaluation  based  on  TCSEC  requirements  by  a  qualified  team  of  experts  and 
maintaining  a  list  of  those  products  on  the  Evaluated  Products  List  (EPL).  To  accom¬ 
plish  this  mission,  the  NCSC  Trusted  Product  Evaluation  Program  has  been  estab- 
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lished  to  assist  vendors  in  developing,  testing,  and  evaluating  trusted  products  for 
the  EPL. 

During  the  evaluation  process,  the  TCSEC  for  classes  Cl  through  A1  requires  a  deter¬ 
mination  that  the  security  features  of  a  system  are  implemented  as  designed  and 
that  they  are  adequate  for  the  specified  level  of  trust.  In  addition,  the  TCSEC  also  re¬ 
quires  documentation  to  support  a  system's  security.  During  the  various  phases  of 
the  evaluation  process,  the  vendor  supplies  to  an  evaluation  team  certain  informa¬ 
tion  on  system  security  and  documentation.  The  purpose  of  the  Trusted  Product 
Evaluation  Questionnaire  (product  questionnaire)  is  to  assist  system  developers  and 
vendors  as  a  data  gathering  tool  for  formalizing  the  data  gathering  process  for  the 
various  phases  of  the  Trusted  Products  Evaluation  process. 

Examples  in  this  document  are  not  to  be  construed  as  the  only  implementations  that 
may  answer  the  questionnaire.  The  examples  are  suggestions  of  appropriate  imple¬ 
mentations.  The  recommendations  in  this  document  are  also  not  to  be  construed  as 
supplementary  requirements  to  the  questionnaire. 


2.  SCOPE 

The  questionnaire  will  address  the  TCSEC  Criteria  Classes  Cl  thru  A1.  In  an  effort  to 
gather  a  better  understanding  of  the  system  security,  some  questions  in  the  ques¬ 
tionnaire  address  information  in  addition  to  that  required  in  the  Department  of  De¬ 
fense  Trusted  Computer  Systems  Evaluation  Criteria.  This  document  is  organized  by 
Criteria  class  subject  area.  The  information  provided  in  the  questionnaire  by  the 
vendor  is  to  assist  the  evaluator  in  obtaining  an  initial  understanding  of  the  system 
applying  for  evaluation  and  its  security  features  of  the  respective  Criteria  class.  The 
product  questionnaire  is  not  a  statement  of  requirements,  just  an  information  gath¬ 
ering  tool.  This  questionnaire  should  give  the  vendor  an  idea  of  the  information  re¬ 
quired  by  the  evaluator  during  the  evaluation  process  and  prepare  the  vendor  for 
additional  information  necessary  by  the  evaluation  team  later  on  in  the  evaluation 
process. 

The  questionnaire  will  be  initially  sent  out  to  the  vendor  prior  to  the  Preliminary 
Technical  Review  (PTR).  The  vendor  can  point  to  appropriate  documents  for  the  an- 
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swers.  The  vendor  need  not  answer  the  questions  that  are  not  pertinent.  Some  of 
the  questions  may  be  applicable  at  the  later  stages  of  the  evaluation  process  and 
thus  may  be  deferred  until  the  appropriate  time.  The  vendor  will  send  a  completed 
questionnaire  to  NCSC  prior  to  the  PTR.  The  PTR  team  will  evaluate  the  vendor  con¬ 
tribution  and  determine  which  information  needs  further  elaboration.  The  PTR 
team  will  use  the  questionnaire  during  the  PTR  to  seek  additional  information  used 
later  on  in  the  evaluation  process.  When  an  evaluation  team  has  reached  the  Design 
Analysis  and  IPAR  preparation  phase,  it  will  use  the  questionnaire  to  seek  specific  re¬ 
ferences  in  vendor  documentation  for  further  details  on  the  answers  to  these  ques¬ 
tions. 

The  document  is  to  provide  the  evaluator  an  understanding  of  the  various  hardware 
and  software  configurations,  architecture  and  design,  testing,  and  documentation, 
system  security  features  and  their  applicability  to  security  and  accountability  policy, 
Trusted  Computing  Base  (TCB)  isolation  and  noncircumventability,  and  covert  chan¬ 
nel  analysis  methods.  Also  this  questionnaire  may  request  information  on  penetra¬ 
tion  testing  and  specification-to-code  correspondence. 

This  questionnaire  is  designed  for  the  operating  systems  only.  This  questionnaire 
does  not  address  networks,  subsystems  nor  data  base  management. 

For  definition  and  clarification  of  the  terms  used  in  this  document,  please  see  the 
Glossary  section  of  the  Department  of  Defense  Trusted  Computer  System  Evaluation 
Criteria  (DOD  5200.28-STD)  and  Glossary  of  Computer  Security  Terms  (NCSC-TG- 
004). 

Review  of  this  document  will  occur  periodically  or  when  the  need  arises.  Address  all 
proposals  for  revision  through  appropriate  channels  to: 

National  Computer  Security  Center 
9800  Savage  Road 

Fort  George  G.  Meade,  MD  20755-6000 

Attention:  Chief,  Criteria  and  Technical  Guidelines 
Division 
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QUESTIONNAIRE 


1.  SUBJECTS 

A  subject  is  an  active  entity  in  the  system,  generally  in  the  form  of  a  person,  process, 
or  device  that  causes  information  to  flow  among  objects  or  changes  the  system  state. 
A  subject  can  be  viewed  as  a  process/domain  pair  whose  access  controls  are  checked 
prior  to  granting  the  access  to  objects. 

1.  What  are  the  subjects  in  your  system? 


2.  When  and  how  are  the  subjects  created?  (For  example,  they  can  be  created  or 
activated  when  a  user  logs  on  or  when  a  process  is  spawned.) 


3.  When  and  how  are  the  subjects  destroyed?  (For  example,  they  can  be  de¬ 
stroyed  or  deactivated  when  a  process  terminates  or  when  the  user  logs  off.) 


4.  What  are  the  security  attributes  of  a  subject?  (Examples  of  security  attributes 
are  user  name,  group  id,  sensitivity  level,  etc.)  For  each  type  of  subject  in  your 
system  (i.e.  user,  process,  device),  what  mechanisms  are  available  to  define 
and  modify  these  attributes?  Who  can  invoke  these  mechanisms? 


5.  What  are  other  privileges  a  subject  can  have?  (Examples  of  privileges  are:  su¬ 
per  user,  system  operator,  system  administrator,  etc.  Your  operating  system 
may  assign  numerous  other  privileges  to  the  subjects,  such  as  the  ability  to  use 
certain  devices.)  For  each  type  of  subject  in  your  system,  what  mechanisms  are 
available  to  define  and  modify  these  privileges?  Who  can  invoke  these 
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mechanisms?  Provide  a  list  of  subjects  within  the  TCB  boundary  and  the  list  of 
privileges  for  each  of  them. 


6.  When  a  subject  is  created,  where  do  its  security  attributes  and  privileges  origi¬ 
nate,  i.e.,  how  are  the  security  attributes  and  privileges  inherited?  (Questions 
about  security  attributes  and  privileges  will  be  asked  later.  For  example,  a 
subject  may  inherit  a  subset  of  attributes  and  privileges  of  the  invoking  pro¬ 
cess  or  the  user.) 
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2.  OBJECTS 


Examples  of  objects  in  a  system  are  directories,  files,  segments,  processes,  devices, 
etc. 


7.  List  the  objects  in  your  system  that  are  protected  by  the  Discretionary  Access 
Control  (DAC)  mechanisms. 


8.  List  the  objects  in  your  system  that  are  protected  by  the  Mandatory  Access 
Control  (MAC)  mechanisms. 


9.  List  the  objects  that  are  not  protected  by  either  the  DAC  or  the  MAC  mecha¬ 
nism.  Why  are  they  not  protected  by  the  DAC  or  the  MAC?  Describe  other 
mechanisms  used  to  isolate  and  protect  these  objects. 


10.  List  other  shared  resources  which  are  not  protected  by  the  DAC  or  the  MAC 
mechanism.  (Examples  include  print  queues,  interprocess  communications, 
etc.)  Why  are  they  not  protected  by  the  DAC  or  the  MAC?  Describe  the 
mechanisms  that  are  used  to  isolate  and  protect  these  resources. 


11.  How  are  the  various  types  of  objects  created  (e.g.,  directories,  files,  devices)? 


1 2.  How  are  the  various  types  of  objects  destroyed? 
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13.  Provide  a  list  of  objects  within  the  TCB  (e.g.,  authentication  database,  print 
queues). 
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3.  HARDWARE  ARCHITECTURE 


If  this  evaluation  is  for  a  family  of  hardware,  the  following  questions  (14-24)  should 
be  answered  for  each  member  of  the  hardware  family.  You  may  choose  to  answer 
each  question  for  each  member  of  the  family,  or  answer  each  question  for  a  baseline 

family  member  and  point  out  the  difference  for  each  of  the  remaining  family  mem- 
bers. 

14.  Provide  a  high-level  block  diagram  of  the  system.  The  diagram  should  depict 
various  Central  Processor  Units  (CPUs),  memory  controllers,  memory,  I/O  pro¬ 
cessors,  I/O  controllers,  I/O  devices  (e  g.  printers,  displays,  disks,  tapes,  commu¬ 
nications  lines)  and  relationships  (both  control  flow  and  data  flow)  among 
them. 


15.  Provide  a  high-level  block  diagram  of  a  CPU.  The  diagram  should  explain  the 
relationship  among  the  following  elements:  Instruction  Processor,  Microse¬ 
quencer,  Microengine,  Memory,  Cache,  Memory  Mapping  or  Address  Transla¬ 
tion  Unit,  I/O  devices  and  interfaces. 


16.  Provide  a  list  of  privileged  instructions  for  your  hardware.  Provide  a  brief  de¬ 
scription  of  each  privileged  instruction. 


17.  For  each  privileged  instruction,  provide  the  privileges  required  to  execute  the 
instruction.  (Examples  of  privileges  include  the  machine  state,  the  executing 
ring/segment,  physical  memory  location  of  the  instruction,  etc.) 
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18.  How  does  the  process  address  translation  (logical/virtual  to  physical)  work  in 
your  system? 


19.  How  does  I/O  processing  address  translation  work  for  the  Direct  Memory  Ac¬ 
cess  (DMA)  controllers/devices?  Identify  if  the  address  translation  is  done 
through  the  memory  address  translation  unit  or  if  the  logic  is  part  of  the  con¬ 
troller.  How  are  the  address  translation  maps  and/or  tables  initialized? 


20.  Describe  the  hardware  protection  mechanisms  provided  by  the  system. 


21.  Describe  the  isolation  mechanisms  for  the  process  memory.  Two  possible 
techniques  are  rings  and  segments. 

22.  Provide  a  description  of  the  process  address  space.  When  and  how  is  it 
formed? 


23.  What  are  the  machine/processor  states  supported  by  the  system?  How  are  the 
states  changed?  What  data  structures  are  saved  as  part  of  the  processor  state? 


24.  List  all  the  interrupts  and  traps  (hardware  and  software).  How  are  they  ser¬ 
viced  by  the  system? 
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4.  SOFTWARE 


The  TCB  software  consists  of  the  elements  that  are  involved  in  enforcing  the  system 
security  policy.  Examples  of  the  TCB  elements  include:  kernel,  interrupt  handlers, 
process  manager,  I/O  handlers,  I/O  manager,  user/process  interface,  hardware  diag¬ 
nostics,  hardware  exercisers,  and  command  languages/interfaces  (for  system  genera¬ 
tion,  operator,  administrator,  users,  etc.).  The  security  kernel  consists  of  the  hard¬ 
ware,  firmware  and  software  elements  of  the  TCB  that  are  involved  in  implementing 

the  reference  monitor  concept,  i.e.,  the  ones  that  mediate  all  access  to  objects  by 
subjects. 

25.  Provide  a  description  and  architecture  of  the  Trusted  Computing  Base  (TCB)  at 
the  element  level. 


26.  Describe  the  interfaces  (control  and  data  flow)  among  the  TCB  elements. 


27.  Describe  the  interface  between  the  kernel  and  the  rest  of  the  TCB  elements. 


28.  Describe  the  interface  between  the  TCB  and  user  processes  that  are  outside 
the  TCB. 


29.  Describe  the  hardware  ring/memory  segment/physical  location  where  each 
TCB  element  resides. 


10 


30.  Describe  the  hardware  ring/memory  segment/physical  location  where  the  user 
processes  reside. 


31.  List  software  mechanisms  that  are  used  to  isolate  and  protect  the  TCB  and  the 
user  processes.  Provide  a  brief  description  of  each  mechanism. 


32.  List  all  the  privileges  a  process  can  have.  Include  the  privileges  based  on  the 
process  or  user  profile,  process  or  user  name,  or  process  or  user  identification. 


33.  How  is  a  process  created?  How  is  a  process  destroyed? 


34.  How  are  a  process's  privileges  determined? 


35.  Describe  various  elements  of  the  process  address  space  and  their  location  in 
terms  of  ring/segment/physical  memory. 


36.  Describe  the  process  states.  (Examples  of  process  states  are  active,  ready  for 
execution,  suspended,  swapped  out,  etc.) 
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Describe  how  these  states  are  manipulated  by  the  TCB. 


Describe  the  data  structures  for  a  process  context.  Describe  both  hardware 
and  software  mechanisms  used  to  manipulate/switch  the  process  context. 


Describe  process  scheduling. 


Describe  all  interprocess  communications  mechanisms. 


Describe  the  file  management  system.  This  should  include:  the  directory  hier¬ 
archy,  if  any,  directory  and  file  attributes.  Also  identify  all  system  directories 
and  files,  and  their  access  attributes. 


Describe  how  the  devices  and  their  queues  are  managed.  Examples  of  devices 
include  tape  drives,  non-file-system  disks,  printers,  etc. 


How  are  the  batch  jobs  and  their  queues  managed? 


What  software  engineering  tools  and  techniques  were  used  for  the  TCB  de¬ 
sign  and  implementation? 


45. 

How  is  a  process  sensitivity  level  determined? 

46. 

How  was  the  modularity  requirement  achieved  and  implemented? 

47. 

For  each  TCB  element,  identify  protection-critical  portions  of  the  code.  De¬ 
scribe  the  protection-critical  functions  performed  by  the  code. 

48. 

For  each  TCB  element,  identify  non-protection-critical  portions  of  the  code. 

Explain  why  the  code  is  part  of  the  TCB. 

49. 

How  was  the  data  abstraction  and  information  hiding  requirement  achieved 
and  implemented? 

50. 

Is  the  TCB  layered?  If  yes,  how  many  layers  are  in  the  TCB?  Provide  a  brief  de¬ 
scription  of  modules  and  functions  in  each  layer.  How  are  the  lower  layers 
protected  from  higher  layers? 
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5.  IDENTIFICATION  &  AUTHENTICATION  (l&A) 


51.  Does  the  system  require  the  users  to  provide  identification  at  login?  If  yes, 
what  information  is  requested  by  the  system? 


52.  Is  there  any  additional  device  or  physical  security  required  for  user  l&A  (e  g., 
terminal  ID,  pass  key,  smart  card,  etc.)? 


53.  Is  each  user  uniquely  identified? 


54.  Does  the  system  authenticate  this  identity  at  the  time  of  login?  If  yes,  what  in¬ 
formation  is  requested  by  the  system?  How  does  the  system  use  this  informa¬ 
tion  to  authenticate  the  identity? 


55.  Describe  the  algorithms  used  in  user  authentication.  Where  in  the  system  are 
the  algorithms  and  data  for  authentication  (e.g.,  user/password  data  base) 
stored? 


56.  How  are  the  authentication  algorithms  and  data  protected? 


57.  Does  the  l&A  process  associate  privileges  with  the  user?  If  so,  what  and  how? 
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58.  Does  the  l&A  process  associate  a  sensitivity  level  with  the  user?  If  so,  how? 
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6.  OBJECT  REUSE 


59.  How  are  the  storage  resources  cleared?  Examples  include  writing  predefined 
patterns,  writing  random  patterns,  preventing  reading  before  writing,  etc. 
When  are  the  storage  resources  cleared:  prior  to  allocation  or  after  dealloca¬ 
tion  and/or  release?  Describe  the  TCB  hardware,  software  and  procedures 
used  in  clearing  these  resources.  Please  answer  this  question  for  each  type  of 
storage  resource.  (Example  of  storage  resources  include  memory  pages, 
cache,  disk  sectors,  magnetic  tapes,  removable  disk  media,  terminals,  etc.) 


60.  Is  it  possible  to  read  the  data  that  have  been  deleted?  For  example,  what  hap¬ 
pens  when  a  process  attempts  to  read  past  the  end-of-file  (EOF)  mark?  In  this 
case,  is  it  possible  to  read  old  data  by  going  past  the  EOF? 
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7.  DISCRETIONARY  ACCESS  CONTROL  (DAC)  POLICY 


61.  What  mechanisms  are  used  to  provide  discretionary  access  controls?  (Exam¬ 
ples  of  mechanisms  are:  access  control  lists,  protection  bits,  capabilities,  etc.) 


62.  Can  the  access  be  granted  to  the  users  on  an  individual  user  basis?  If  so,  how? 


63.  Can  access  be  denied  to  the  users  on  an  individual  user  basis,  i.e.,  exclude  indi¬ 
vidual  users?  If  so,  how? 


64.  Can  the  access  be  granted  to  groups  of  individuals?  If  so,  how? 


65.  Can  the  access  be  denied  to  groups  of  individuals?  If  so,  how? 


66.  How  is  a  group  defined?  Who  has  the  ability  to  create  or  delete  groups?  Who 
has  the  ability  to  add  or  delete  users  from  a  group? 


67.  What  are  the  initial  access  permissions  when  an  object  is  created?  Can  the  ini¬ 
tial  access  permission  be  changed?  If  so,  by  whom  and  how?  (User/owner,  sys¬ 
tem  administrator,  others.) 
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68.  Can  different  initial  access  permissions  be  specified  for  different  users,  or  is 
this  is  a  system-wide  setting?  If  the  former,  by  whom  and  how? 


69.  Who  can  grant  the  access  permissions  to  an  object  after  the  object  is  created? 
(Examples  include  creator,  current  owner,  system  administrator,  etc.)  How  is 
the  permission  granted? 


70.  Can  the  ability  to  grant  permissions  be  passed  to  another  user?  If  so,  by  whom 
and  how?  How  can  the  previous  owner  of  the  privilege  still  retain  it? 


71 .  How  can  the  access  be  revoked  on  an  individual  user  basis? 


72.  How  can  the  access  be  revoked  on  a  group  basis? 


73.  Are  any  objects  that  can  be  accessed  by  other  users  excluded  from  the  DAC 
policy  (e.g.,  IPC  files,  process  signaling/synchronization  flags)? 


74.  For  each  TCB  object  identified  in  13,  describe  the  DAC  mechanism. 
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75.  List  the  access  modes  supported  by  the  system.  Examples  of  access  modes  are: 
read,  write,  delete,  owner,  execute,  append,  etc.  Briefly  describe  the  meaning 
of  each  access  mode  for  each  class  of  object. 


76.  For  questions  62-72,  how  can  the  access  modes  be  explicitly  defined? 


8.  LABELS 


77.  How  many  hierarchical  sensitivity  classifications  (such  as  unclassified,  confi¬ 
dential,  secret,  top  secret),  does  your  system  provide  for?  What  mechanisms 
are  available  to  define  the  internal/storage  and  external/print  format?  What 
mechanisms  are  available  to  change  them?  Who  can  invoke  these  mecha¬ 
nisms? 


78.  How  many  nonhierarchical  sensitivity  categories  (such  as  FOUO)  does  your  sys¬ 
tem  provide  for?  What  mechanisms  are  available  to  define  the  inter¬ 
nal/storage  and  external/print  format?  What  mechanisms  are  available  to 
change  them?  Who  can  invoke  these  mechanisms? 


79.  What  is  the  internal  TCB  storage  format  of  the  sensitivity  label? 


80.  For  each  type  of  subject,  where  is  the  subject  sensitivity  label  stored? 


81 .  For  each  type  of  object,  where  is  the  object  sensitivity  label  stored? 


82.  List  the  subjects  and  objects  that  are  labeled  and  not  labeled.  Why  are  they  la¬ 
beled  or  not  labeled?  How  are  these  subjects  and  objects  controlled? 
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83.  How  is  imported  (brought-in)  data,  labeled?  Is  a  human  being  involved  in  the 
labeling?  If  so,  what  is  the  role  of  the  person  involved?  Does  this  labeling  re¬ 
quire  special  privileges?  What  are  those  privileges? 


84.  Who  can  change  the  labels  on  a  subject?  How? 


85.  Who  can  change  the  labels  on  an  object?  How? 


86.  How  are  the  labels  associated  with  objects  communicated  outside  the  TCB? 


87.  How  does  the  TCB  acknowledge  a  change  in  the  sensitivity  level  associated 
with  an  interactive  user?  Is  the  user  notification  posted  on  the  user  terminal? 
How  immediate  is  this  change? 


88.  How  does  a  user  query  the  system  TCB  for  his  or  her  current  sensitivity  label? 
What  part  of  the  sensitivity  label  is  output?  Where  is  this  output  posted? 


89.  How  does  the  system  designate  each  device  to  be  single-level  or  multilevel? 
List  the  ways  this  designation  can  be  changed.  List  the  users  who  can  invoke 
these  mechanisms/ways. 
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90.  How  does  the  TCB  designate  the  sensitivity  level  of  a  single-level  device?  List 
the  ways  this  designation  can  be  changed.  List  the  users  who  can  invoke  these 
mechanisms. 


91.  How  does  the  TCB  designate  the  minimum  and  maximum  sensitivity  levels  of  a 
device?  List  the  ways  these  designations  can  be  changed.  List  the  users  who 
can  invoke  these  mechanisms. 


92.  How  does  the  TCB  export  the  sensitivity  label  associated  with  an  object  being 
exported  over  a  multilevel  device?  What  is  the  format  for  the  exported  label? 
How  does  the  TCB  ensure  that  the  sensitivity  label  is  properly  associated  with 
the  object? 


93.  What  mechanisms  are  available  to  specify  the  human-readable  print  label  as¬ 
sociated  with  a  sensitivity  label?  Who  can  invoke  these  mechanisms? 


94.  Is  the  beginning  and  end  of  each  hardcopy  output  marked  with  the  human- 
readable  print  label  representing  the  sensitivity  level  of  the  output?  In  other 
words,  does  each  hardcopy  output  have  banner  pages?  What  happens  if  a 
banner  page  output  is  longer  and/or  wider  than  a  physical  page? 
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95.  Is  the  top  and  bottom  of  each  hardcopy  output  page  marked  with  the  human- 
readable  print  label  representing  the  sensitivity  level  of  the  output?  What 
happens  if  the  print  label  is  wider  and/or  longer  than  the  space  available  for 
the  top  and/or  the  bottom? 


96.  How  does  the  TCB  mark  the  top  and  bottom  page  of  nontextual  type  of  out¬ 
put  such  as  graphics,  maps,  and  images? 


97.  How  can  these  markings  listed  in  questions  94-96  be  overridden?  Who  can 
override  the  markings? 


98.  How  can  an  operator  distinguish  the  TCB-generated  banner  pages  from  user 
output? 


99.  What  is  the  sensitivity  label  for  each  TCB  object  listed  in  question  13? 


100.  Can  a  minimum  sensitivity  level  be  specified  for  each  physical  device?  If  so, 
how? 


101.  Can  a  maximum  sensitivity  level  be  specified  for  each  physical  device?  If  so, 
how? 
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102.  List  the  circumstances  under  which  the  TCB  allows  input  or  output  of  data  that 
fall  outside  a  device  sensitivity  range  (i.e.,  minimum,  maximum). 
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9.  MANDATORY  ACCESS  CONTROL  (MAC) 

103.  Describe  the  MAC  policy  for  the  possible  access  modes  such  as  read,  write,  ap¬ 
pend,  delete. 


104.  Does  the  system  use  sensitivity  labels  to  enforce  the  MAC?  If  not,  what  infor¬ 
mation  is  used  to  make  the  MAC  decisions? 


105.  List  the  subjects,  objects,  and  circumstances  under  which  the  MAC  policy  is  not 
enforced.  Why? 


106.  In  what  sequence  does  the  system  check  for  detecting  access  mechanisms  such 
as:  a.  privileges  that  bypass  DAC  and  MAC,  b.  DAC,  c.  MAC,  d.  other  access 
mechanisms  in  lieu  of  DAC  and/or  MAC? 


107.  Does  the  TCB  support  system-low  and  system-high  sensitivity  levels?  If  yes, 
how  can  they  be  designated  and  changed?  Who  can  invoke  the  functions  to 
designate  and  change  them?  How  are  these  levels  used  by  the  system  in  var¬ 
ious  labeling  functions  and  MAC  decisions? 
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10.  INTEGRITY 


108.  How  many  hierarchical  integrity  categories  does  your  system  provide  for? 
What  mechanisms  are  available  to  define  the  internal/storage  and  exter¬ 
nal/print  format?  Who  can  invoke  these  mechanisms? 


109.  How  many  nonhierarchical  integrity  compartments  does  your  system  provide 
for?  What  mechanisms  are  available  to  define  the  internal/storage  and  exter¬ 
nal/print  format?  Who  can  invoke  these  mechanisms? 


110.  What  is  the  internal  TCB  storage  format  of  the  integrity  label? 


111.  For  each  type  of  subject,  where  is  the  subject  integrity  label  stored? 


1 12.  For  each  type  of  object,  where  is  the  object  integrity  label  stored? 


113.  List  the  subjects  and  objects  that  do  not  have  integrity  labels.  Why  are  they 
not  labeled? 


1 14.  How  are  the  data  that  are  imported  (brought  in)  labeled  with  an  integrity  la¬ 
bel?  Is  a  human  being  involved  in  the  labeling?  If  so,  who  is  it?  Does  the  user 
labeling  require  special  privileges?  What  are  those  privileges? 
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115.  Who  can  change  the  integrity  labels  on  a  subject?  How? 


116.  Who  can  change  the  integrity  labels  on  an  object?  How? 


117.  Describe  the  integrity  policy  for  various  access  modes  such  as  read  and  write. 
Provide  a  brief  description  of  the  formal  policy  model. 


1 1 8  Does  the  system  use  the  integrity  labels  to  enforce  the  integrity  policy?  If  not, 
what  information  is  used  to  enforce  the  integrity  policy? 


119.  List  the  subjects,  objects,  and  circumstances  under  which  the  integrity  policy  is 
not  enforced.  Why? 
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11.  AUDIT 


120.  Provide  a  brief  description  (preferably  in  block  diagram  form)  of  audit  data 
flow  in  terms  of  how  the  data  are  created,  transmitted,  stored,  and  viewed  for 
analysis.  How  are  the  audit  logs  protected? 


121.  How  can  the  audit  log  be  read?  Who  can  invoke  these  mechanisms? 


122.  How  can  the  audit  log  be  written  or  appended?  Who  can  invoke  these 
mechanisms? 


123.  How  can  the  audit  log  be  deleted?  Who  can  invoke  these  mechanisms? 


124.  Provide  a  list  of  auditable  events.  Are  the  following  events  auditable:  at¬ 
tempted  logins,  logouts,  creation  of  subjects,  deletion  of  subjects,  assignment 
of  privileges  to  subjects,  change  of  subject  privileges,  use  of  privileges  by  sub¬ 
jects,  creation  of  objects,  deletion  of  objects,  initial  access  to  objects  (in  other 
words  introduction  of  the  object  into  user  address  space  or,  e.g.,  file  open),  ac¬ 
cesses  that  exploit  covert  storage  channels,  change  in  the  device  designation 
of  single-level  or  multilevel,  change  in  device  level,  change  in  device  minimum 
or  maximum  level,  override  of  banner  page  or  page  top  and  bottom  mark¬ 
ings,  assumption  of  the  role  of  security  administrator. 
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125.  Which  actions  by  the  privileged  users  are  auditable?  Which  are  not?  Exam¬ 
ples  of  trusted  users  are  system  operator,  account  administrator,  system  secu¬ 
rity  officer/administrator,  auditor,  system  programmer,  etc. 


1 26.  What  data  are  recorded  for  each  audit  event?  Are  the  following  data  record¬ 
ed  for  each  event:  date,  time,  user,  user  sensitivity  level,  object,  object  sensi¬ 
tivity  level,  object  DAC  information  (e.g.,  ACL),  type  of  event,  invoked  or  not 
invoked,  why  not  invoked,  success  or  failure  in  execution,  terminal  identifica¬ 
tion,  etc? 


127.  Under  what  circumstances  can  the  password  become  part  of  the  audit  record? 


128.  What  mechanisms  are  available  to  designate  and  change  the  activities  being 
audited?  Who  can  invoke  these  mechanisms? 


1 29.  What  mechanisms  are  available  for  selective  auditing  (i.e.,  selection  of  events, 
subjects,  objects,  etc.,  to  be  audited)?  What  parameters  or  combination  of  pa¬ 
rameters  can  be  specified  for  the  selective  auditing?  Examples  of  parameters 
are:  individual  or  group  of  subjects,  individual  objects,  subjects  within  a  sensi¬ 
tivity  range,  objects  within  a  sensitivity  range,  event  type,  etc.  Who  can  in¬ 
voke  these  mechanisms? 
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130.  When  do  changes  to  the  audit  parameters  take  effect  (e.g.,  immediately  for 
all  processes,  for  new  processes)? 


131.  What  tools  are  available  to  output  raw  or  processed  (i.e.,  analyzed  and  re¬ 
duced)  audit  information?  Who  can  invoke  these  tools?  What  do  the  tools  do 
in  terms  of  audit  data  reduction?  What  are  the  internal  formats  of  audit 
records.  What  are  the  formats  of  the  reports/outputs  generated  by  these 
tools? 


1 32.  Are  the  audit  reduction  tools  Dart  of  the  TCB?  If  not,  is  there  a  trusted  mecha¬ 
nism  to  view/output  the  audit  log? 


1 33.  Does  the  system  produce  multiple  audit  logs?  If  yes,  what  tools,  techiques  and 
methodologies  are  available  to  correlate  these  logs? 


134.  Who  (e.g.,  operator,  system  administrator  or  other  trusted  user)  is  notified 
when  the  audit  loq  gets  full?  What  options  are  available  to  handle  the  situa¬ 
tion? 


135.  What  other  action  does  the  TCB  take  when  the  audit  log  becomes  full?  Exam- 
Dles  of  the  TCB  ODtions  are:  halt  the  svstem.  do  not  Derform  auditable  events, 
overwrite  oldest  audit  log  data.  etc.  In  the  worst  case,  how  much  audit  data 
can  be  lost?  Describe  the  worst  case  scenario.  When  does  it  occur? 


1 36.  What  happens  to  the  audit  data  in  the  memory  buffers  when  the  system  goes 
down?  Are  the  data  recovered  as  part  of  the  system  recovery?  In  the  worst 
case,  how  much  data  can  be  lost?  Describe  the  worst  case  scenario.  When 
does  it  occur? 


137.  How  does  the  TCB  designate  and  change  the  occurrence  or  accumulation  of 
events  that  require  real-time  notification?  Who  can  invoke  these  mecha¬ 
nisms?  Who  gets  the  real-time  notification?  What  actions/options  are  avail¬ 
able  to  the  individual  being  notified?  What  does  the  TCB  do  about  the  event 
and  the  process  that  caused  this  alert? 


12.  MODELING  AND  ANALYSIS 


138.  Provide  a  copy  of  the  Verification  Plan,  a  brief  description  of  its  contents,  or 

an  annotated  outline.  Provide  a  schedule  for  completion  of  the  Verification 
Plan. 


139.  What  tools,  techniques  and  methodologies  are  used  to  represent  the  formal 
model  of  the  system  security  policy?  What  policies  are  represented  in  the  for¬ 
mal  model.  Examples  include:  MAC,  DAC,  privileges,  other  protection  mecha¬ 
nisms,  object  reuse,  etc. 


140.  What  tools,  techniques  and  methodologies  are  used  to  verify  through  formal 
means  the  model  against  its  axioms? 


141.  What  tools,  techniques  and  methodologies  are  used  to  represent  the  Descrip¬ 
tive  Top  Level  Specification  (DTLS)?  What  portions  of  the  TCB  are  represented 
by  the  DTLS? 


142.  What  tools,  techniques  and  methodologies  are  used  to  identify,  analyze,  cal¬ 
culate,  and  reduce  the  bandwidths  of  data  flows  in  violation  of  the  system  se¬ 
curity  policy?  How  are  the  occurrences  of  these  flow  violations  audited? 
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143.  What  tools,  techniques  and  methodologies  are  used  to  show  that  the  DTLS  is 
consistent  with  the  formal  security  policy  model? 


144.  What  tools,  techniques  and  methodologies  are  used  to  represent  the  Formal 
Top  Level  Specification  (FTLS)?  What  portions  of  the  TCB  are  represented  by 
the  FTLS? 


145.  What  tools,  techniques  and  methodologies  are  used  to  verify  or  show  that  the 
FTLS  is  consistent  with  the  formal  security  policy  model? 


146  What  tools,  techniques  and  methodologies  are  used  to  identify  the  imple¬ 
mented  code  modules  that  correspond  to  the  FTLS? 


147.  What  tools,  techniques  and  methodologies  are  used  to  show  that  the  code  is 
correctly  implemented  vis-a-vis  the  FTLS? 
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13.  TESTING 


148.  What  routines  are  available  to  test  the  correct  operation  of  the  system  hard¬ 
ware  and  firmware?  What  elements  of  the  system  hardware  are  tested 
through  these  routines?  What  elements  of  the  system  firmware  are  tested 
through  these  routines?  What  elements  of  the  system  hardware  and  firm¬ 
ware  are  not  tested  through  these  routines? 


149.  How  are  the  system  hardware  and  firmware  tested?  Does  the  testing  include 
boundary  and  anomalous  conditions?  Is  the  emphasis  on  diagnosing  and  pin¬ 
pointing  faults  or  is  it  on  ensuring  the  correct  operation  of  the  system  hard¬ 
ware  and  firmware?  The  latter  may  require  more  of  the  same  testing  or  dif¬ 
ferent  kinds  of  testing. 


150.  How  are  these  routines  invoked?  Who  can  invoke  these  routines?  Do  they 
run  under  the  control  of  the  operating  system  or  do  they  run  in  stand-alone 
mode? 


151.  When  can  these  routines  be  run?  When  should  these  routines  be  run?  If  they 
run  automatically,  when  do  they  run?  Examples  include  powerup,  booting,  re¬ 
booting..  etc. 


152.  Describe  the  software  development  testing  methodology.  In  the  methodol¬ 
ogy,  include  various  testing  steps  such  as  unit,  module,  integration,  subsys¬ 
tem,  system  testing.  For  each  step,  provide  a  description  of  test  coverage  cri¬ 
teria  and  test  cases  development  methodology. 


34 


1 53.  Provide  a  copy  of  the  security  test  plan,  brief  description  of  its  contents,  or  an 
annotated  outline.  Does  the  test  plan  include  the  following  information:  sys¬ 
tem  configuration  for  testing,  procedures  to  generate  the  TCB,  procedures  to 
bring  up  the  system,  testing  schedule,  test  procedures,  test  cases,  expected 
test  results?  Provide  a  schedule  for  development  of  the  security  test  plan. 


154.  How  thorough  is  the  security  testing?  Do  the  test  cases  include  nominal, 
boundary,  and  anomalous  values  for  each  input?  What  about  the  combina¬ 
tions  of  inputs?  Describe  the  test  coverage  criteria. 


155.  How  are  the  test  cases  developed?  Are  they  based  on  the  concept  of  func¬ 
tional  testing,  structural  testing,  or  a  combination  of  the  two? 


1 56.  What  tools  and  techniques  (automated,  manual,  or  a  combination  of  the  two) 
will  be  used  to  do  the  functional  and/or  structural  analysis  in  order  to  develop 
a  thorouah  set  of  test  cases?  Indicate  how  vou  olan  to  use  FTLS  and  DTLS  in 
tnis  analysis.  If  you  do  not  pian  to  use  tnem,  how  do  you  plan  to  snow  consis¬ 
tency  among  FTLS,  DTLS,  and  the  code? 


1 57.  How  do  you  Dlan  to  develoD  the  scenarios  tor  penetration  testina  ? 


1 58.  How  do  you  plan  to  test  the  bandwidths  of  flow  violation  channels? 


1 59.  How  do  you  plan  to  ascertain  that  only  a  few  errors  remain? 


36 


14.  OTHER  ASSURANCES 

160  Describe  the  Configuration  Management  (CM)  system  in  place  in  terms  of  or¬ 
ganizational  responsibilities,  procedures,  and  tools  and  techniques  (automat¬ 
ed,  manual,  or  a  combination  of  the  two).  Describe  the  version  control  or 
other  philosophy  to  ensure  that  the  elements  represent  a  consistent  system, 
i.e.,  object  code  represents  the  source  code,  which  in  turn  represents  the  FTLS 
and  DTLS,  etc.  If  the  CM  system  is  different  for  some  of  the  elements  listed  un¬ 
der  Question  25,  answer  this  question  for  each  of  the  elements. 


161.  When  was  the  CM  instituted?  Provide  the  approximate  date  as  well  as  the  sys¬ 
tem  life-cycle  phase  (e  g.  design,  development,  testing). 


1 62.  List  the  TCB  elements  that  are  under  the  Configuration  Management.  List  the 
TCB  elements  that  are  not  under  CM.  Examples  of  TCB  elements  are:  hard¬ 
ware  elements,  firmware  elements,  formal  security  policy  model,  FTLS,  DTLS, 
design  data  and  documentation,  source  code,  object  code,  software  engineer¬ 
ing  environment,  test  plans,  Security  Features  User's  Guide,  Trusted  Facilities 
Manual,  etc. 


1 63.  Describe  the  protection  mechanisms  in  place  to  safeguard  the  CM  elements. 
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1 64.  When  (e.g.,  before  user  authentication)  and  how  (e.g.  by  typing  a  specific  con¬ 
trol  character  sequence)  can  the  trusted  path  be  invoked  by  the  user?  What 
TCB  elements  are  involved  in  establishing  the  trusted  oath? 


165.  List  separately  the  functions  that  can  be  performed  by  each  of  the  trusted  us¬ 
ers  such  as  the  operator,  security  administrator,  accounts  administrator,  audi¬ 
tor,  systems  programmer,  etc.  For  each  of  these  persons/roles,  list  the  system 
data  bases  that  can  be  accessed  and  their  access  modes.  For  each  of  these 
roles,  also  list  the  privileges  provided  to  them. 


166.  How  does  the  TCB  recognize  that  a  user  has  assumed  one  of  the  above- 
mentioned  trusted  roles?  Which  of  the  above-mentioned  functions  can  be 
performed  without  the  TCB  recognizing  this  role? 


167.  When  and  how  does  the  TCB  invoke  the  trusted  path?  What  TCB  elementsare 
involved  in  estaolishing  the  trusted  patn  ? 


168.  How  does  the  TCB  ensure  that  the  trusted  path  is  unspoofable? 


169.  How  does  the  system  recovery  work?  What  system  resources  (e.g.,  memory, 
disks  blocks,  files)  are  protected  prior  to  and  during  the  system  recovery?  How 
are  they  protected?  What  resources  are  not  protected? 
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170.  Does  the  system  have  a  degraded  mode  of  operation?  What  can  cause  this  to 
occur?  How  long  can  the  system  keep  running  in  this  mode?  How  does  an  op¬ 
erator  get  the  system  back  to  full  operation?  What  security-related  services 
are  provided  in  the  degraded  mode?  What  security-related  services  are  not 
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171.  Describe  the  tools,  techniques  and  procedures  used  to  ensure  the  integrity  of 
the  TCB  elements  (hardware,  firmware,  software,  documents,  etc.)  supplied  to 
the  customers.  Examples  include  trusted  courier,  electronic  seals,  physical 
seals,  etc. 
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15.  OTHER  DOCUMENTATION 


172.  Describe  the  methodology  used  in  the  design  of  the  system.  Provide  a  list  of 
documents  that  capture  the  system  design.  For  each  document,  provide  a 
copy,  a  brief  description  of  its  contents,  or  an  annotated  outline.  Provide  a 
schedule  for  development  of  the  design  documents. 


1 73.  Provide  a  copy  of  the  Security  Features  User's  Guide  (SFUG),  a  brief  description 
of  its  contents,  or  an  annotated  outline.  Does  the  document  describe  the  pro¬ 
tection  mechanisms  available  to  the  users?  Does  it  include  examples  of  how 
to  use  the  protection  mechanisms  in  conjunction  with  one  another  to  meet 
the  user  security  objectives?  Provide  a  schedule  for  development  of  the  SFUG. 


174.  Provide  a  copy  of  the  Trusted  Facility  Manual  (TFM),  a  brief  description  of  its 

contents,  or  an  annotated  outline.  Provide  a  schedule  for  development  of  the 
TFM. 


175.  Does  the  TFM  contain  procedures  to  configure  the  secure  system?  Does  it  list 
the  devices  and  hardware  elements  that  are  part  of  the  evaluated  configura¬ 
tion?  Does  it  contain  procedures  for  configuring  each  of  the  devices,  for  con¬ 
necting  them,  and  for  configuring  the  entire  system?  Does  it  list  the  devices 
that  are  not  part  of  the  evaluated  configuration?  Does  it  list  the  procedures 
for  securely  configuring  them  out  and  for  disconnectina  them? 
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176.  Does  the  TFM  contain  procedures  to  generate  the  TCB  from  source  code?  For 
each  system  parameter  or  input,  does  the  TFM  list  valid  values  for  a  secure  TCB 
generation? 


177.  Does  the  TFM  list  the  functions,  privileges,  and  data  bases  that  are  to  be  con¬ 
trolled?  Does  it  list  how  these  are  controlled?  Does  it  list  the  consequences  of 
granting  access  to  them  as  warnings? 


178.  Does  the  TFM  provide  procedures  for  maintaining  the  audit  log?  Does  it  de¬ 
scribe  how  the  audit  log  can  be  turned  on,  turned  off,  combined,  and  backed 
up?  Does  it  describe  how  to  detect  the  audit  log  is  getting  full,  or  is  full,  and 
what  actions  to  take  in  order  to  minimize  the  loss  of  audit  data? 


179.  Does  the  TFM  contain  the  structure  of  the  audit  log  file  and  the  format  of  the 
audit  records?  Does  it  describe  how  the  audit  records  can  be  viewed?  Does  it 
describe  the  capabilities  of  the  audit  reduction  tool,  how  to  invoke  these  ca¬ 
pabilities,  and  the  format  of  the  tool  output? 


180.  Does  the  TFM  contain  the  procedures  and  warnings  for  secure  operation  of 
the  computing  facility?  Does  it  address  the  physical,  personnel,  and  adminis¬ 
trative  aspects  of  security  in  order  to  ensure  the  protection  of  computing 
hardware,  firmware,  software,  and  privileged  devices  such  as  the  operator 
terminals?  Does  it  address  the  protection  of  hard-copy  outputs? 
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181.  Does  the  TFM  provide  a  list  of  trusted  users  and  processes?  For  each  trusted 
user  or  process,  does  it  list  the  functions,  privileges,  and  data  bases  to  be  ac¬ 
cessed?  Examples  of  trusted  users  are  system  operator,  security  administrator, 
accounts  administrator,  auditor,  etc.  Examples  of  trusted  processes  are  device 
queue  manipulation,  user  profile  editor,  etc.  Examples  of  functions  are  creat¬ 
ing  and  deleting  users,  changing  user  security  profile,  setting  up  defaults  for 
discretionary  and  mandatory  access  controls,  selecting  auditing  events  in 
terms  of  functions,  subjects,  objects,  sensitivity  levels,  and/or  a  combination  of 
them,  etc.  Examples  of  data  bases  are  user  security  profiles,  authentication 
data  base,  etc. 


182.  Does  the  TFM  include  a  list  of  TCB  modules  that  make  up  the  security  kernel? 


183.  Does  the  TFM  contain  the  procedures  for  securely  starting/booting/initializing 
the  system? 


184.  Does  the  TFM  contain  the  procedures  for  securely  restarting/resuming  the  sys¬ 
tem  after  a  lapse  in  system  operation? 


185.  Does  the  TFM  contain  the  procedures  for  securely  recovering  the  system  after 
a  system  failure? 
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GLOSSARY 


Access 

A  specific  type  of  interaction  between  a  subject  and  an  object  that  results  in 
the  flow  of  information  from  one  to  the  other. 


Access  List 

A  list  of  users,  programs,  and/or  processes  and  the  specifications  of  access 
categories  to  which  each  is  assigned. 


Administrative  User 

A  user  assigned  to  supervise  all  or  a  portion  of  an  ADP  system. 


Audit 

To  conduct  the  independent  review  and  examination  of  system  records  and 
activities. 

Audit  Trail 

A  chronological  record  of  system  activities  that  is  sufficient  to  enable  the  re¬ 
construction,  reviewing,  and  examination  of  the  sequence  of  environments 
and  activities  surrounding  or  leading  to  an  operation,  a  procedure,  or  an 
event  in  a  transaction  from  its  inception  to  final  results. 

Auditor 

An  authorized  individual,  or  role,  with  administrative  duties,  which  include  se¬ 
lecting  the  events  to  be  audited  on  the  system,  setting  up  the  audit  flags  that 
enable  the  recording  of  those  events,  and  analyzing  the  trail  of  audit  events. 

Authenticate 

(1)  To  verify  the  identity  of  a  user,  device,  or  other  entity  in  a  computer  sys¬ 
tem,  often  as  a  prerequisite  to  allowing  access  to  resources  in  a  system. 

(2)  To  verify  the  integrity  of  data  that  have  been  stored,  transmitted,  or  other¬ 
wise  exposed  to  possible  unauthorized  modification. 
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Authenticated  User 

A  user  who  has  accessed  an  ADP  system  with  a  valid  identifier  and  authentica¬ 
tion  combination. 

Authorization 

The  granting  of  access  rights  to  a  user,  program,  or  process. 

Bandwidth 

A  characteristic  of  a  communication  channel  that  is  the  amount  of  informa¬ 
tion  that  can  be  passed  through  it  in  a  given  amount  of  time,  usually  ex¬ 
pressed  in  bits  per  second. 

Bell-LaPadula  Model 

A  formal  state  transition  model  of  computer  security  policy  that  describes  a 
set  of  access  control  rules.  In  this  formal  model,  the  entities  in  a  computer  sys¬ 
tem  are  divided  into  abstract  sets  of  subjects  and  objects.  The  notion  of  a  se¬ 
cure  state  is  defined,  and  it  is  proven  that  each  state  transition  preserves  secu¬ 
rity  by  moving  from  secure  state  to  secure  state,  thereby  inductively  proving 
that  the  system  is  secure.  A  system  state  is  defined  to  be  "secure"  if  the  only 
permitted  access  modes  of  subjects  to  objects  are  in  accordance  with  a  specific 
security  policy.  In  order  to  determine  whether  or  not  a  specific  access  mode  is 
allowed,  the  clearance  of  a  subject  is  compared  to  the  classification  of  the  ob¬ 
ject,  and  a  determination  is  made  as  to  whether  the  subject  is  authorized  for 
the  specific  access  mode.  The  clearance/classification  scheme  is  expressed  in 
terms  of  a  lattice.  See  Star  Property  (* -property)  and  Simple  Security  Property. 

Channel 

An  information  transfer  path  within  a  system.  May  also  refer  to  the  mecha¬ 
nism  by  which  the  path  is  effected. 

Covert  Channel 

A  communication  channel  that  allows  two  cooperating  processes  to  transfer 
information  in  a  manner  that  violates  the  system's  security  policy. 
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Covert  Storage  Channel 

A  covert  channel  that  involves  the  direct  or  indirect  writing  of  a  storage  loca¬ 
tion  by  one  process  and  the  direct  or  indirect  reading  of  the  storage  location 
by  another  process.  Covert  storage  channels  typically  involve  a  finite  resource 
(e.g.,  sectors  on  a  disk)  that  is  shared  by  two  subjects  at  different  security  lev¬ 
els. 

Covert  Timing  Channel 

A  covert  channel  in  which  one  process  signals  information  to  another  by  mod¬ 
ulating  its  own  use  of  system  resources  (e.g.,  CPU  time)  in  such  a  way  that  this 
manipulation  affects  the  real  response  time  observed  by  the  second  process. 

Coverage  Analysis 

Qualitative  or  quantitative  assessment  of  the  extent  to  which  the  test  condi¬ 
tions  and  data  show  compliance  with  required  properties  (e.g.,  security  model 
and  TCB  primitive  properties).  See:  Test  Condition,  Test  Data,  Security  Policy 
Model. 

Data 

Information  with  a  specific  physical  representation. 

Data  Integrity 

The  property  that  data  meet  an  a  priori  expectation  of  quality. 

Degauss 

To  reduce  magnetic  flux  density  to  zero  by  applying  a  reverse  magnetizing 
field. 

Descriptive  Top  Level  Specification  (DTLS) 

A  top-level  specification  that  is  written  in  a  natural  language  (e.g. .English),  an 
informal  program  design  notation,  or  a  combination  of  the  two. 


Discretionary  Access  Control  (DAC) 

A  means  of  restricting  access  to  objects  based  on  the  identity  and  need-to- 
know  of  the  user,  process  and/or  groups  to  which  they  belong.  The  controls 
are  discretionary  in  the  sense  that  a  subject  with  a  certain  access  permission  is 
capable  of  passing  that  permission  (perhaps  indirectly)  on  to  any  other  sub¬ 
ject. 

Dominate 

Security  level  Si  is  said  to  dominate  security  level  S2  if  the  hierarchical  classifi¬ 
cation  of  Si  is  greater  than  or  equal  to  that  of  S2  and  the  nonhierarchical  cate¬ 
gories  of  Si  include  all  those  of  S2  as  a  subset. 

Exploitable  Channel 

Any  channel  that  is  usable  or  detectable  by  subjects  external  to  the  Trusted 
Computing  Base  whose  purpose  is  to  violate  the  security  policy  of  the  system. 


Flaw 

An  error  of  commission,  omission,  or  oversight  in  a  system  that  allows  protec¬ 
tion  mechanisms  to  be  bypassed. 

Flaw  Hypothesis  Methodology 

A  system  analysis  and  penetration  technique  in  which  specifications  and  docu¬ 
mentation  for  the  system  are  analyzed  and  then  flaws  in  the  system  are  hy¬ 
pothesized.  The  list  of  hypothesized  flaws  is  prioritized  on  the  basis  of  the  es¬ 
timated  probability  that  a  flaw  actually  exists  and,  assuming  a  flaw  does  exist, 
on  the  ease  of  exploiting  it  and  on  the  extent  of  control  or  compromise  it 
would  provide.  The  prioritized  list  is  used  to  direct  a  penetration  attack 
against  the  system. 

Formal  Proof 

A  complete  and  convincing  mathematical  argument,  presenting  the  full  logi¬ 
cal  justification  for  each  proof  step,  for  the  truth  of  a  theorem  or  set  of  theo¬ 
rems. 


46 


Formal  Security  Policy  Model 

A  mathematically  precise  statement  of  a  security  policy.  To  be  adequately 
precise,  such  a  model  must  represent  the  initial  state  of  a  system,  the  way  in 
which  the  system  progresses  from  one  state  to  another,  and  a  definition  of  a 
"secure"  state  of  the  system.  To  be  acceptable  as  a  basis  for  a  TCB,  the  model 
must  be  supported  by  a  formal  proof  that  if  the  initial  state  of  the  system  sat¬ 
isfies  the  definition  of  a  "secure"  state  and  if  all  assumptions  required  by  the 
model  hold,  then  all  future  states  of  the  system  will  be  secure.  Some  formal 
modeling  techniques  include:  state  transition  models,  temporal  logic  models, 
denotational  semantics  models,  algebraic  specification  models. 

Formal  Top-Level  Specification  (FTLS) 

A  Top-Level  Specification  that  is  written  in  a  formal  mathematical  language  to 
allow  theorems  showing  the  correspondence  of  the  system  specification  to  its 
formal  requirements  to  be  hypothesized  and  formally  proven. 

Formal  Verification 

The  process  of  using  formal  proofs  to  demonstrate  the  consistency  between  a 
formal  specification  of  a  system  and  a  formal  security  policy  model  (design 
verification)  or  between  the  formal  specification  and  its  program  implemen¬ 
tation  (implementation  verification). 

Functional  Testing 

The  segment  of  security  testing  in  which  the  advertised  mechanisms  of  a  sys¬ 
tem  are  tested,  under  operational  conditions,  for  correct  operation. 

Identification 

The  process  that  enables  recognition  of  an  entity  by  a  system,  generally  by  the 
use  of  unique  machine-readable  user  names. 

Integrity 

Sound,  unimpaired  or  perfect  condition. 
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Internal  Security  Controls 

Hardware,  firmware,  and  software  features  within  a  system  that  restrict  access 
to  resources  (hardware,  software,  and  data)  to  authorized  subjects  only  (per¬ 
sons,  programs,  or  devices). 

Isolation 

The  containment  of  subjects  and  objects  in  a  system  in  such  a  way  that  they 
are  separated  from  one  another,  as  well  as  from  the  protection  controls  of  the 
operating  system. 

Lattice 

A  partially  ordered  set  for  which  every  pair  of  elements  has  a  greatest  lower 
bound  and  a  least  upper  bound. 

Least  Privilege 

This  principle  requires  that  each  subject  in  a  system  be  granted  the  most  re¬ 
strictive  set  of  privileges  (or  lowest  clearance)  needed  for  the  performance  of 
authorized  tasks.  The  application  of  this  principle  limits  the  damage  that  can 
result  from  accident,  error,  or  unauthorized  use. 

Mandatory  Access  Control  (MAC) 

A  means  of  restricting  access  to  objects  based  on  the  sensitivity  (as  repre¬ 
sented  by  a  label)  of  the  information  contained  in  the  objects  and  the  formal 
authorization  (i.e.,  clearance)  of  subjects  to  access  information  of  such  sensi¬ 
tivity. 

Multilevel  Device 

A  device  that  is  used  in  a  manner  that  permits  it  to  simultaneously  process 
data  of  two  or  more  security  levels  without  risk  of  compromise.  To  accomplish 
this,  sensitivity  labels  are  normally  stored  on  the  same  physical  medium  and  in 
the  same  form  (i.e.,  machine-readable  or  human-readable)  as  the  data  being 
processed. 
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Object 

A  passive  entity  that  contains  or  receives  information.  Access  to  an  object  po¬ 
tentially  implies  access  to  the  information  it  contains.  Examples  of  objects 
are:  records,  blocks,  pages,  segments,  files,  directories,  directory  tree,  and  pro¬ 
grams,  as  well  as  bits,  bytes,  words,  fields,  processors,  video  displays,  key¬ 
boards,  clocks,  printers,  network  nodes. 

Object  Reuse 

The  reassignment  and  reuse  of  a  storage  medium  (e.g.,  page  frame,  disk  sec¬ 
tor,  magnetic  tape)  that  once  contained  one  or  more  objects.  To  be  securely 
reused  and  assigned  to  a  new  subject,  storage  media  must  contain  no  residual 
data  (magnetic  remanence)  from  the  object(s)  previously  contained  in  the  me¬ 
dia. 

Penetration 

The  successful  act  of  bypassing  the  security  mechanisms  of  a  system. 

Process 

A  program  in  execution. 

Protection-Critical  Portions  of  the  TCB 

Those  portions  of  the  TCB  whose  normal  function  is  to  deal  with  the  control  of 
access  between  subjects  and  objects.  Their  correct  operation  is  esssential  to 
the  protection  of  data  on  the  system. 


Read 

A  fundamental  operation  that  results  only  in  the  flow  of  information  from  an 
object  to  a  subject. 

Read  Access  (Privilege) 

Permission  to  read  information. 

Reference  Monitor  Concept 

An  access-control  concept  that  refers  to  an  abstract  machine  that  mediates  all 
accesses  to  objects  by  subjects. 


49 


Security  Level 

The  combination  of  a  hierarchical  classification  and  a  set  of  nonhierarchical 
categories  that  represents  the  sensitivity  of  information. 

Security  Policy 

The  set  of  laws,  rules,  and  practices  that  regulate  how  an  organization  man¬ 
ages,  protects,  and  distributes  sensitive  information. 

Security  Policy  Model 

A  formal  presentation  of  the  security  policy  enforced  by  the  system.  It  must 
identify  the  set  of  rules  and  practices  that  regulate  how  a  system  manages, 
protects,  and  distributes  sensitive  information.  See  Bell-La  Padula  Model  and 
Formal  Security  Policy  Model. 

Security-Relevant  Event 

Any  event  that  attempts  to  change  the  security  state  of  the  system,  (e.g., 
change  discretionary  access  controls,  change  the  security  level  of  the  subject, 
change  user  password).  Also,  any  event  that  attempts  to  violate  the  security 
policy  of  the  system,  (e.g.,  too  many  attempts  to  log  in,  attempts  to  violate  the 
mandatory  access  control  limits  of  a  device,  attempts  to  downgrade  a  file). 

Security  Testing 

A  process  used  to  determine  that  the  security  features  of  a  system  are  imple¬ 
mented  as  designed.  This  includes  hands-on  functional  testing,  penetration 
testing,  and  verification. 

Simple  Security  Property 

A  Bell-La  Padula  security  model  rule  allowing  a  subject  read  access  to  an  ob¬ 
ject  only  if  the  security  level  of  the  subject  dominates  the  security  level  of  the 
object.  Also  called  simple  security  condition. 

Single-Level  Device 

An  automated  information  systems  device  that  is  used  to  process  data  of  a 
single  security  level  at  any  one  time. 


50 


Spoofing 

An  attempt  to  gain  access  to  a  system  by  posing  as  an  authorized  user.  Syn¬ 
onymous  with  impersonating,  masquerading  or  mimicking. 

Star  Property 

A  Bell-La  Padula  security  model  rule  allowing  a  subject  write  access  to  an  ob¬ 
ject  only  if  the  security  level  of  the  object  dominates  the  security  level  of  the 
subject.  Also  called  confinement  property,  *-property. 

Subject 

An  active  entity,  generally  in  the  form  of  a  person,  process,  or  device,  that 
causes  information  to  flow  among  objects  or  changes  the  system  state.  Tech¬ 
nically,  a  process/domain  pair. 

Subject  Security  Level 

A  subject's  security  level  is  equal  to  the  security  level  of  the  objects  to  which  it 
has  both  read  and  write  access.  A  subject's  security  level  must  always  be  domi¬ 
nated  by  the  clearance  of  the  user  the  subject  is  associated  with. 

Terminal  Identification 

The  means  used  to  provide  unique  identification  of  a  terminal  to  a  system. 

Test  Condition 

A  statement  defining  a  constraint  that  must  be  satisfied  by  the  program  under 
test. 

Test  Data 

The  set  of  specific  objects  and  variables  that  must  be  used  to  demonstrate  that 
a  program  produces  a  set  of  given  outcomes. 

Test  Plan 

A  document  or  a  section  of  a  document  which  describes  the  test  conditions, 
data,  and  coverage  of  a  particular  test  of  group  of  tests.  See  also:  Test  Condi¬ 
tion,  Test  Data,  Coverage  Analysis. 
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Test  Procedure  (Script) 

A  set  of  steps  necessary  to  carry  out  one  or  a  group  of  tests.  These  include 
steps  for  test  environment  initialization,  test  execution,  and  result  analysis. 
The  test  procedures  are  carried  out  by  test  operators. 

Test  Program 

A  program  which  implements  the  test  conditions  when  initialized  with  the 
test  data  and  which  collects  the  results  produced  by  the  program  being  tested. 

Top-Level  Specification  (TLS) 

A  nonprocedural  description  of  system  behavior  at  the  most  abstract  level, 
typically,  a  functional  specification  that  omits  all  implementation  details. 

Trusted  Computer  System 

A  system  that  employs  sufficient  hardware  and  software  integrity  measures  to 
allow  its  use  for  processing  simultaneously  a  range  of  sensitive  or  classified  in¬ 
formation. 

Trusted  Computing  Base  (TCB) 

The  totality  of  protection  mechanisms  within  a  computer  system  -  including 
hardware,  firmware,  and  software  -  the  combination  of  which  is  responsible 
for  enforcing  a  security  policy.  It  creates  a  basic  protection  environment  and 
provides  additional  user  services  required  for  a  trusted  computer  system.  The 
ability  of  a  trusted  computing  base  to  correctly  enforce  a  security  policy  de¬ 
pends  solely  on  the  mechanisms  within  the  TCB  and  on  the  correct  input  by 
system  administrative  personnel  of  parameters  (e  g.,  a  user's  clearance)  re¬ 
lated  to  the  security  policy. 

Trusted  Path 

A  mechanism  by  which  a  person  at  a  terminal  can  communicate  directly  with 
the  Trusted  Computing  Base.  This  mechanism  can  only  be  activated  by  the 
person  or  the  Trusted  Computing  Base  and  cannot  be  imitated  by  untrusted 
software. 
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User 


Person  or  process  accessing  an  AIS  either  by  direct  connections  (i.e.,  via  termi¬ 
nals),  or  indirect  connections  (i.e.,  prepare  input  data  or  receive  output  that  is 
not  reviewed  for  content  or  classification  by  a  responsible  individual). 

Verification 

The  process  of  comparing  two  levels  of  system  specification  for  proper  corre¬ 
spondence  (e.g.,  security  policy  model  with  top-level  specification,  TLS  with 
source  code,  or  source  code  with  object  code).  This  process  may  or  may  not  be 
automated. 


Write 

A  fundamental  operation  that  results  only  in  the  flow  of  information  from  a 
subject  to  an  object. 

Write  Access  (Privilege) 

Permission  to  write  an  object. 
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